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Expert  Systems  in  Maintenance  Diagnostics  for 
Seif-Repair  of  Digital  Flight  Control  Systems 


John  Davison 

Air  Force  Flight  Dynamics  Laboratory 


A couple  of  weeks  ago,  the  Flight  Dynamics  Laboratory  (FDL)  of  Wright- 
Patterson  Air  Force  Base  met  with  our  sister  laboratory,  the  Avionics  Laboratory, 
to  exchange  some  ideas  on  artificial  intelligence.  I briefed  them  on  this  workshop 
program  and  they  were  surprised  to  learn  that  FDL  was  going  to  demonstrate  a 
maintenance  diagnostics  system  this  spring.  They  had  not  planned  to  do  this  until 
1987.  They  suggested  that  I contact  Dr.  Richardson  and  this  workshop  and 
communicate  some  of  these  ideas  as  they  think  this  demonstration  is  a well  kept 
secret  of  the  work  we've  been  doing.  However,  I might  add  that  we've  been  too 
busy  working  to  advertise.  * 

? / - f 1 

I'd  like  to  coverSjthree  basic  components  of  this  program.  One  is  an 
overview  and  the  progress  of  the  program  starting  off  with  the  battle  damage 
statistics  that  are  supplied  to  us  by  aircraft  battle  damage  repair  people.  ';These 
statistics  are  the  drivers  that  influence  the  self-repairing  program.  They  are 
gathered  primarily  from  Southeast  Asian  data,  updated  from  the  Falklands 
conflict  and  Israeli  data.  Secondly,  1 would  like  to  talk  briefly  about  the  self- 
repairing concept,  and  thirdly,  the  status  of  our  expert  system  for  maintenance 
diagnostics.  - — 

Figure  1 assumes  a four-to-one  damage/loss  ratio  for  a status  of  the 
fleets  during  surge.  The  dramatic  part  about  the  top  line  is  that  after  the  second 
day,  as  you  can  see,  68  percent  of  all  the  aircraft  are  out  of  commission.  That's 
not  due  to  attrition  alone;  we  have  aircraft  that  are  awaiting  maintenance  and  in 
battle  damage  repair.  Those  are  pretty  alarming  statistics. 

If  we  examine  aircraft  losses  by  functional  area,  we  see  that  flight 
control  is  a large  contributor  along  with  fuel  and  fire  explosion  and  propulsion 
system.  In  aircraft  damages  by  functional  area  of  the  return,  flight  control  is 
again  a large  contributor,  around  18  percent.  However,  when  we  look  at  the 
percentages  of  the  aircraft  returning  with  damage  (see  Figure  2),  propulsion,  fuel, 
power,  and,  of  course,  structural  damage  are  the  real  drivers.  I don't  know  why 
structure  isn't  100  percent,  I think  everything  has  to  go  through  the  structure.  I 
think  this  graph  was  based  on  small  arms  fire  only.  When  we  look  at  the  repair 
time  it  takes  to  turn  the  plane  around,  we  see  that  flight  control  occupies  the 
majority  of  the  median  time  to  repair.  Figure  3 shows  that  even  with  me  advent 
of  digital  electronics  and  the  complexity  of  the  flight  control  systems,  we're  still 
only  at  1 1 percent  of  the  cost  in  the  digital  electronics.  The  drivers  are  still  in 
the  equipment  areas,  for  example,  in  the  servos. 

As  you'll  see  in  Figure  4,  the  self-repairing  system  is  broken  into  three 
general  areas.  The  first  is  the  survivability  of  the  aircraft  where  we're  concerned 
with  real-tirne  configuration  in  case  of  system  faults  and  battle  damage  where  we 
reconstruct  the  forces  and  moments  using  the  remaining  surfaces.  For  the  quick 
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turn  around  of  the  aircraft,  we're  looking  at  automatic  maintenance  diagnostics 
and  we're  using  an  application  of  expert  systems.  Because  we  can  detect  and 
classify  these  failures,  we  want  to  let  the  pilot  know  v hat  capability  remains,  not 
just  what  has  failed. 

To  take  a general  look  at  our  system  in  a single  channel,  the  blocks  in 
solid  lines  in  Figure  5 would  be  a standard  flight  control  system.  The  key  in  this 
system  is  our  system  impairment  detection  classification  function.  This  feeds 
into  a drop-in  module  where  we  remix  the  flight  control  laws  and  send  them  back 
to  the  flight  control  computer  without  changing  those  flight  control  laws  at  all. 
As  long  as  we're  able  to  do  that,  as  I mentioned,  we  give  the  pilots  a real-time 
status  of  what  are  the  operational  capabilities.  For  example,  we  might  tell  them 
that  with  the  remaining  capability  they  can  only  pull  W G's  as  opposed  to  6tt. 

In  our  maintenance  diagnostics,  we  think  that  we're  going  to  follow  the 
TAC  two-level  maintenance  concept  so  that  we  can  data-iink  figures  back  to  the 
forward  base.  If  the  pilot  has  a servo  that  has  failed  or  experienced  damage,  the 
mechanic  will  be  waiting  with  a part  at  hand  as  the  plane  taxis  up.  However,  it's 
really  not  our  idea  that  maintenance  begins  in  the  air.  Other  people  have  been 
doing  it  for  a long  time.  We  do  think  that  we  have  a little  different  approach  to 
the  problem,  though.  This  is  where  we  get  into  our  maintenance  diagnostics 
computer.  In  our  approach,  the  troubleshooting  expert  is  paramount.  We're  also 
going  to  use  in-flight  faults,  the  situation  data,  and  we're  going  to  incorporate  the 
technical  orders  and  the  illustrated  parts  breakdown  in  our  maintenance 
diagnostics  computer. 

The  general  components  of  the  expert  system  are  the  same.  As  you'll 
see  in  Figure  6,  in  the  knowledge  base  we  use  the  heuristics  and  the  rules  of  logic 
and  in  the  situation  base  we  use  current  data,  historical  facts,  and  background 
information.  That's  also  where  we  put  all  our  flat  file  data  for  all  the  prioritized 
possible  faults.  It  gees  directly  into  our  maintenance  computer,  and  that 
computer  interrogates  the  maintenance  person.  For  example,  we're  experiencing 
in-flight  faults  and,  let's  say  we  had  a problem  in  the  pitch  axis,  it  would  drop  us 
right  into  the  pitch  axis  diagnostics.  Part  way  through  the  diagnostics  the 
computer  may  ask  maintenance  if  the  follow-up  potentiometer  in  the  pitch 
actuator  has  been  checked.  If  the  maintenance  person  punches  the  "no"  button, 
the  next  question  would  be,  "Do  you  know  where  it's  at?"  If  the  "no"  button  gets 
punched  again,  we  bring  up  the  illustrated  parts  breakdown  technical  order  file 
and  draw  a tone  over  the  follow-up  pot  to  indicate  exactly  where  it's  located. 
Then  we  explain  how  to  go  about  checking  that  and  clear  the  system. 

We're  looking  at  two  possible  applications.  For  new  applications,  we'd 
like  the  computer  to  be  autonomous  and  reside  in  aircraft.  Right  now,  we're 
trying  to  impact  existing  aircraft  like  the  F- 15  and  the  F-16  (Figure  7). 

Question:  » have  a problem:  Why  would  you  do  that  when  it's  sent  in 
subject  to  battle  damage? 

Davison:  It  can  be  stand-alone,  or  because  it  is  stand-alone,  we  can  roll 
another  one  up  in  front  if  it  does  have  battle  damage.  But  we  don't  want  to  get 
into  the  redundancy,  triplex  and  quad  of  everything  in  airplanes.  It  can  be  easily 
substituted. 
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EXISTING  AIRCRAFT  RETROFIT: 


I heard  a lot  of  conversation  this  morning  about  the  quality  of 
maintenance  personnel  and  the  problems  involved  with  troubleshooting  the 
system.  Let  me  tell  you  that  flight  control  systems  are  complex.  There's  digital, 
quad,  fly-by-wire  systems,  and  I don't  care  if  you're  a control  engineer  or  a 
mechanic,  when  you  open  up  that  panel  and  try  to  troubleshoot  that  system,  it's 
like  a hog  looking  at  a wristwatch.  I mean,  you  don't  know  where  to  begin.  We 
think  this  self-repairing  system  is  the  only  way  we  can  circumvent  that  problem. 

We  think  we're  really  a little  bit  ahead  of  the  game  because  we've  relied 
on  General  Electric  and  have  a contract  with  them  to  develop  this  system.  We're 
riding  on  the  coattails  of  their  DELTA  system,  the  locomotive  system  for 
maintenance  diagnostics.  This  is  supported  with  both  Air  Force  funds  and  IR<5cD 
funds.  In  order  to  develop  their  DELTA  system,  it  took  them  12  months  to  get  a 
50  rule  feasibilitv  demo  model.  It  took  another  year  to  bring  it  into  lab  prototype 
and  a third  year  to  a field  prototype  model— that's  at  around  500  rules.  To  get 
into  a 1200  rule  system,  it’s  4 years  and  about  a megabyte  of  memory. 

Figure  S shows  where  we  are  right  now.  We're  going  to  use  the  F-18 
because  it's  the  only  production  digital  fly -by -wire  system  available  now.  We're 
going  to  develop  a 50  rule  system  and  demonstrate  this  in  the  coming  spring. 
We're  moving  this  technology  into  our  AFTIF-16  and  by  March  of  1986,  we  hope  to 
have  a 1200  rule  system  developed  and  in  place. 

To  wind  this  up,  we  want  to  look  at  both  the  on-board  diagnostics  and  be 
able  to  data  link  this  data  back  to  the  forward  base.  This  will  provide  rapid 
assessment  of  fault  and  damage.  We  want  to  incorporate  all  the  technical  orders 
into  the  flight  hardware.  We  want  to  impact  that  median  repair  time  of  43  hours 
(rf.  Figure  2)  and  reduce  it  by  a factor  of  five.  By  incorporating  those  technical 
orders  in  there,  we  eliminate  a ground-support  function,  so  we  don't  have  to 
divert  to  the  large  fixed  infrastructure- type  bases.  We  can  divert  anywhere,  the 
maintenance  people  can  rendezvous  with  the  airplane  and  hopefully  perform 
maintenance  tha*  would  normally  be  performed  at  the  depot  level. 

Question:  I don't  understand  why  you  call  it  self-repairing? 

Davison:  Well,  we're  reconfiguring  the  flight  r^ntrol  laws.  Regarding 

self -repairing,  we're  talking  about  the  system  level.  We're  not  using  artificial 
intelligence  to  reconfigure  the  system;  that's  another  presentation. 

Question:  Doesn't  the  maintenance  person  still  make  the  replacement? 

Davison:  Yes,  but  we're  saying  that  we  can  do  away  with  the 

unscheduled  maintenance  and  continue  to  fly  by  being  able  to  detect,  isolate,  and 
recover  from  any  failure  in  the  system. 

Thank  you. 
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